Secure network access method

ABSTRACT

The present invention provides network-layer authentication protocols for authenticating mobile client and access router to each other. The present invention uses Router Discovery as a carrier to implement the authentication protocols. In an embodiment of the present invention, a mobile client sends out a solicitation message to request connectivity service. The solicitation message contains a proof of identity of the mobile client. An access router that receives the solicitation message will not respond to it until the proof of the identity is verified. Only when the proof of identity of the mobile client is verified, will the access router respond and return an advertising message to the mobile client, thereby preventing unauthorized mobile clients from obtaining network access.

[0001] This application claims the benefit of U.S. ProvisionalApplication No. 60/345,967, filed Nov. 9, 2001, entitled “Secure NetworkAccess Using Router Discovery and AAA,” which is hereby incorporated byreference.

[0002] This application is also cross referenced to a non-provisionalapplication No. 10/146,548 filed May 15, 2002 entitled “METHOD FORSECURING ACCESS TO MOBILE IP NETWORK,” and U.S. Provisional ApplicationNo. 60/332,396, filed Nov. 9, 2001, entitled “MOBILE IP REGISTRATION,”both of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION

[0003] This invention relates in general to two-way security protocolsfor authenticating clients and access routers to each other when theclients seek connectivity service for network access and when therouters offer network connectivity. The security protocols according tothe present invention build upon AAA (Authentication, Authorization andAccounting) and use Router Discovery as a carrier for implementing thesecurity protocols.

[0004] Public access IP networks are widely deployed with theproliferation of globally routable IP-aware devices, such as cell phonesand personal digital assistants (PDA). Especially, the progress incellular radio technology and the growth rate of the cellular telephonesystems over the last several years is indicative of tremendous marketdemand for location independent communication. The role of wireless hasgone well beyond the traditional voice and paging mobile radio servicesof a few short years ago. The International Telecommunication Union(ITU), the recognized authority for worldwide network standards, hasrecently published its International Mobile Telecommunications-2000(IMT-2000) standard. The standard proposes so-called third generation(3G) networks that include extensive mobile access by wireless, mobileclients including cellular phones, PDAs, handheld computers, and thelike. In the proposed 3G networks, mobile clients, or roaming clients,are free to move and allowed to change their points of attachment fromone base station to another while maintaining access to networkresources. Some of the 3G networks provide mobility at link layer (layer2). But the future networks (so called 4G) are expected to providemobility at IP layer (layer 3).

[0005] The Internet Engineering Task Force (IETF), an internationalcommunity of network designers, operators, vendors, and researchersconcerned with the evolution of the Internet architecture and the smoothoperation of the Internet, have proposed several standards for mobilitysupport at IP layer. These include proposed standards for IP MobilitySupport such as IETF RFC 2002, also referred to as Mobile IP Version 4(IPv4), and draft working document <draft-ietf-mobileip-ipv6-17>entitled “Mobility Support in IPv6,” also referred to as Mobile IPVersion 6, both of which are incorporated herein by reference. Accordingto the protocol operations defined in Mobile IPv4 and IPv6, whilemaintaining access to network resources, a client is allowed to moveover networks and change its point of attachment from one access routerto another. This operation is commonly referred to as “Layer 3 (L3)handoff.”

[0006] The purpose of performing the L3 handoff operation is to updatepacket routing information on a roaming client through a registrationprocess. A client is always addressable by its “home address,” an IPaddress assigned to the client by an access router on the home network(home router) or chosen by the client itself. While situated away fromits home on a foreign network, however, a client is configured with acare-of address which indicates the client's current point of attachmentto the network. The care-of address is the address of an access routeron the foreign network (foreign router), and the client operating awayfrom home registers its care-of address with its home router. The homerouter that has received a registration request then intercepts packetsdestined for the client and routes the packets to the client's care-ofaddress. In Mobile IPv6, a client away from home sends a binding updateto its home router and any correspondent node in communication. Acorrespondent node may be a mobile client like the client or may be aserver that provides date to the client. The correspondent node that hasreceived the binding update then sends packets directly to the clientwithout routing them through the home router.

[0007] A crucial security issue arises when a roaming client seeksnetwork connectivity in a visited network. The client has to beauthenticated before any network access is granted to it. Anunauthenticated client may be a free-loader that tries to access networkresources under a false or stolen ID. Such a client may also be amalicious node seeking network access only for the purpose of disruptingthe orderly operation of networks. Similarly, clients may want toauthenticate access routers which are offering network connectivity tothe client. The access router may be a rogue router that will eavesdropthe client's communication or divert the communication to somewhere elseor just drop the communication. Currently, there are numerousauthentication mechanisms implemented and deployed for various accesstechnologies. Examples include authentication of PPP and 802.11networks. One drawback to utilizing these networks is that thesenetworks provide link-layer solutions; as such their applicability islimited to specific access technologies. It is clearly beneficial toprovide a network-layer solution because network-layer solutions do notchoose radio access technologies that function below it.

BRIEF SUMMARY OF THE INVENTION

[0008] The present invention provides network-layer protocols forauthenticating mobile client and access router to each other before anynetwork access is granted to the mobile client. The present inventionuses Router Discovery as a carrier to implement the authenticationprotocols. In an embodiment of the present invention, a mobile clientsends out a solicitation message to request connectivity service. Thesolicitation message contains a proof of identity of the mobile client.An access router that receives the solicitation message will not respondto it until the proof of the identity is verified. Only when the proofof identity of the mobile client is verified, will the access routerrespond and return an advertising message to the mobile client, therebypreventing unauthorized mobile clients from obtaining network access.

[0009] The advertising message from an access router may contain a proofof identity of the access router. The mobile client will initiatenetwork access via the access router only when the proof of the accessrouter is successfully verified, thereby preventing mobile clients frombeing lured to begin network access via an illegitimate access router.

[0010] Using solicitation and advertising messages has advantages insecuring network access. The Discovery mechanism is the first step formobile client and access router to establish off-link connectivity. Inother words, using the Discovery mechanism for the purpose ofauthenticating mobile client and access router is a natural extension toan already established protocol. Piggybacking the authentication ofmobile client and access router to the Discovery mechanism will achievesignificant saving of protocol signaling, which is critical for mobileand wireless networks where communication resources are precious andexpensive. Another advantage of using the Discovery mechanism is thatthe Discovery mechanism is common to both IPv4 and IPv6. Therefore, thepresent invention, which uses the Discovery mechanism as a carrier forimplementing the authentication of mobile client and access router, willbe implementable in networks irrespective of whether the networks adoptIPv4 or IPv6.

[0011] The authentication protocols according to the present inventionmay build on the AAA infrastructure and use the authentication serviceand protocol signaling provided by AAA protocol. Under AAA protocol, aplurality of domains are defined and each served by at least one AAAserver which provides AAA services to mobile clients through attendants,i.e., access routers. In the present invention, a trusted entity isneeded to verify the proof of identity of a client contained in asolicitation message. When the client enters a new foreign domain, thetrusted entity is an AAA server serving the home domain of the client.Thus, protocol signaling for this initial authentication process maytake a long round trip between the client and the home server and maycause communication latency. However, as long as the client stays withinthe foreign domain, the home server will not be consulted forverification. For instance, the server in the foreign domain becomes thetrusted entity when the client switches one access router to another inthe domain. Even an access router may become the trusted entity when theclient seeks connectivity to the same access router. Thus, the protocolsignaling necessary for the authentication protocol according to thepresent invention will take a shorter round trip, and thus thecommunication delays caused by the authentication process will also beshortened.

[0012] The authentication protocol according to the present inventioncan be implemented with any key algorithms, such as symmetric andasymmetric cryptographies. Those keys may be distributed along withprotocol signaling associated with the authentication process accordingto the present invention. Those keys are distributed to establish newsecurity associations between two entities that have had no securityassociation in order to secure the rest of the protocol signaling forNeighbor Discovery, such as address resolution (ARP/RARP), andsubsequent communications between the entities.

[0013] In another embodiment of the present invention, an access routermay voluntarily send out advertising messages that contain a proof ofidentity of the access router. If a client successfully verifies theproof, it begins using the access router as a gateway to the Internet.If the client is unable to verify the proof, it will initiate theauthentication process by sending out a solicitation message thatcontains a proof of its identity. This solicitation message will beprocessed as outlined above.

[0014] In another embodiment of the present invention, a client may sendout a solicitation message to an access router while in communicationwith the access router. There is always the possibility that alegitimate entity is replaced with an illegitimate one even duringcommunication. The solicitation message will trigger to the accessrouter to send out an advertising message that contains a proof ofidentity of the access router, thereby allowing the client tore-authenticate the access router during communication. Similarly, anaccess router may send out an advertising message with short routerlifetime to a client with which the access router is in communication.In response, the client will sends out a solicitation message thatcontains a proof of its identity, thereby allowing the access router tore-authenticate the client.

[0015] A solicitation message from a client and/or an advertisingmessage from an access router may contain a challenge to provideprotection against reply attacks.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

[0016]FIG. 1 illustrates an exemplary third generation, wireless, mobileaccess, IP network in which the invention is intended to findapplication;

[0017]FIG. 2 provides a simplified graphical illustration showing thestandard mobile client Layer 3 hand-off process performed in the IPnetwork shown in FIG. 1;

[0018]FIGS. 3A and 3B are simplified graphical representations showing ageneric AAA network model on which authentication protocols according tothe present invention are implemented;

[0019]FIG. 4 is a graphical illustration showing pre-establishedsecurity associations implicit in the network shown in FIGS. 3A and 3B;

[0020]FIG. 5A is a flow chart illustrating a authentication protocolusing Router Discovery mechanism, according to an embodiment of theinvention, in which the identity of a mobile client is verified by itshome server;

[0021]FIG. 5B is a simplified graphical representation of the processflow illustrated in FIG. 5A;

[0022]FIG. 6 is a graphic illustration showing new security associationsestablished between client and access router (SA4) and between clientand AAAF (SA5) after the authentication protocol shown in FIGS. 5A and5B is performed;

[0023]FIG. 7A is a flow chart that illustrates an authenticationprotocol according to another embodiment of the invention in which theidentity of a mobile client is verified by a foreign server;

[0024]FIG. 7B is a simplified graphical representation of the processflow illustrated in FIG. 7A;

[0025]FIG. 8A is a flow chart that illustrates an authenticationprotocol according to another embodiment of the invention in whichclient and access router are re-authenticated;

[0026]FIG. 8B is a simplified graphical representation of the processflow illustrated in FIG. 8A;

[0027]FIG. 9 is a simplified graphical representation showing anotherembodiment of the present invention in which access routers voluntarilysend out their Router Advertisements;

[0028]FIG. 10 is a flow chart illustrating an authentication protocolusing Router Discovery mechanism, according to an embodiment of theinvention, in which solicitation and advertising message contain achallenge to provide protection against replay attacks;

[0029]FIG. 11 is a flow chart illustrating another example ofauthentication protocol performed in the embodiment of the invention asshown in FIG. 10 in which client and access router are re-authenticated;and

[0030]FIG. 12 is a flow chart illustrating a authentication protocolusing Router Discovery mechanism, according to an embodiment of theinvention, in which an asymmetrical key algorithm is used.

DETAILED DESCRIPTION OF THE INVENTION

[0031] The presently preferred embodiments of the invention aredescribed herein with reference to the drawings, wherein like componentsare identified with the same references. The descriptions of thepreferred embodiments contained herein are intended to be exemplary innature and are not intended to limit the scope of the invention. Itshould especially be noted that although the embodiments are describedwith networks that implement Mobile IP, the present invention can beimplemented more broadly with any IP based communication protocols, suchas IPv4 and IPv6.

[0032]FIG. 1 illustrates an exemplary third generation, wireless, mobileaccess, IP network 100 in which the invention is intended to findapplication. For purposes of the present description, it is assumed thedata network 100 adheres to the IMT-2000 standards and specifications ofthe ITU for wireless, mobile access networks. Additionally, it isassumed the data network 100 implements Mobile IP support according tothe proposed Mobile IPv4 and Mobile IPv6 standards of the IETF. Thus, itshould be noted that in this application, terms peculiar to one versionmay be used interchangeably with the corresponding terms for the otherversion. For instance, the term “agent” may be used interchangeably withthe term “access router” or just “router” and so may “Agent Discovery”with “Router Discovery,” “Agent Solicitation” with “Router Solicitation”and “registration request” with “binding update.”

[0033] The wireless, mobile access, IP data network 100 has at its corea fixed node IP data network 120 comprising numerous fixed nodes (notshown), i.e., fixed points of connection or links. Digital data iscommunicated within and over the network in accordance with InternetProtocol version 6 (IPv6). Again, IPv6 is just an example ofcommunication protocol and can be replaced with other communicationprotocols, such as IPv4. Some of the nodes of the core network 120comprise conventional routers (not shown), which function asintermediary nodes in accordance with conventional Internet addressingand routing protocols to route packets of data between source anddestination nodes connected to the network.

[0034] Built on the core 120 is a collection of gateway routers (GR) 130that comprise an IP mobile backbone 140. The gateways 130 comprising theIP mobile backbone are themselves nodes of the core network 120 and areinterconnected via the core network 120. Each gateway 130 has aplurality of access routers 145 connected thereto that can communicatewith mobile clients 135. The mobile clients may comprise any number ofdifferent kinds of mobile, wireless communication devices includinghandsets, cellular telephones, hand-held computers, personal informationmanagers or the like. The access routers 145 function as home routers(HR) and foreign routers (FR) to interface the clients 135 to the corenetwork 120 through gateways 130. The routers 145 are Layer 3 accessnetwork entities. The clients 135 communicate with the routers 145through radio access points (AP) 155. The APs 155 are Layer 2 accessnetwork entities. A group of APs 155 forms a subnetwork 150 in FIG. 1.Each router 145 serves a subnetwork 150 and provides a network link asan interface between the subnetwork 150 and the data network 100. Theclients 135 and the APs employ known CDMA or W-CDMA or similar digitaldata communication technology to communicate with each other.

[0035] Pursuant to Mobile IPv6, each mobile client is assigned a homesubnetwork which comprises a home router 145, which maintains currentlocation information of the client and which may route packets to theclient at its current location. Other access routers 145 function asforeign routers, which a client can “visit” while away from its homesubnetwork area. Whichever home router or foreign router a client 135happens to be communicating with at a given time establishes a networklink and provides network access to the client. Each of the clients andaccess routers in the network has a unique IP address just as inconventional fixed node data networks employing conventional Internetprotocols.

[0036] Within the overall data network 100, two levels of handoffprocesses are contemplated. The first level is a macro-level handoff oran Layer 3 handoff, which involves change in location of a client suchthat it leaves one radio subnetwork served by one access router to go toanother subnetwork served by another access router. Thus, through an L3handoff, the client's network link necessarily changes. The next levelis a micro-level handoff or an Layer 2 handoff, which involves a changein the location of a client within an AP subnetwork 150, in which casethe client's radio link changes but network link does not change. Thehandling of L2 handoff is standard in wireless, cellular communicationnetworks. For example, it is well known to use beacon signal strengthfrom nearby APs for detecting reachability of the nearby APs.

[0037]FIG. 2 provides a simplified graphical illustration of mobileclient L3 handoff process that is performed pursuant to Mobile IPv6. Inthe figure, the network 100 includes the network 120 and routers 145connected to the network 120. A client 135 is originally located at astarting location A and moving toward a location C through anintermediary location B. In the example illustrated, the client 135 atthe starting location A is operating within the foreign subnetworkserved by the foreign router 145 (FR1) and connected to the network 120via the FR1. On the other hand, the location C is located within theforeign subnetwork operated by the foreign router 145 (FR2). The mobileclient 135 is traveling across the subnetwork operated by the FR1 andentering the subnetwork operated by the FR2. Thus, the L3 handoffcontemplated in FIG. 2 takes place on the switching its network linkfrom the FR1 to the FR2.

[0038] As the client moves from the starting location A and arrives atthe intermediary location B, there comes a point where further wirelesscommunication with the FR1 begins to fail. The client is leaving thesubnet 150 operated by the FR1 and about to enter the subnet 150operated by the FR2. As the client passes the intermediary location B,an L2 handoff occurs, so that the client's radio link changes from an APin the subnet served by the FR1 to an AP in the subnet served by theFR2. As moving further towards the destination location C, the clientperforms an L3 handoff or Mobile IP registration with the FR2. Theregistration process begins with the Router Discovery prescribed inMobile IPv6. Through the Router Discovery process, the client locatesnearby access routers, determine their link-layer addresses and maintainreachability information about the paths to the routers. For thesepurposes, Router Discovery defines, among other things, a pair of ICMPpacket types, i.e., Router Solicitation and Router Advertisement. ARouter Solicitation is sent out by a client to request nearby accessrouters to generate and return Router Advertisements. Access Routersadvertise their presence by sending Router Advertisements eitherperiodically or in response to a Router Solicitation from a client.Router Advertisements contain information for clients to configure Careof Addresses (CoA).

[0039] When receiving a Router Advertisement from the FR2, the clientforms a CoA based on the information in the advertisement and configuresitself with the (CoA). The client then registers the new CoA by sendingthe HR a binding update containing both the new CoA and the client'spermanent home IP address. The HR then updates the routing informationof the client in its binding cache, whereby an L3 link is establishedbetween client and FR2. Hereafter, packets transmitted to the home IPaddress of the client will be intercepted by the HR and tunneled by theHR to the FR2 and delivered to the client from the FR2. To eliminatepacket latency caused by triangular routing of packets, the bindingupdate is also sent to any correspondent node which will thereafterroute packets directly to the client.

[0040] As the popularity of mobile data communication increases, so doesthe possibility that malicious clients may try to obtain network access.These malicious mobile clients may be free-loaders trying to accessnetwork resources under a fake or stolen identity. These clients arenothing but a threat to the orderly operation of networks. Thus, toscreen out these malicious clients, clients seeking network access haveto be authenticated before any network access is granted to it.Similarly, clients may want to authenticate access routers offeringconnectivity before beginning network access via these access routers.There may be a rogue access router among them which will eavesdrop theclient's communication or divert the communication to somewhere else orjust drop the communication. The present invention provides two-waysecurity protocols for authenticating clients and access routers to eachother so that both clients and access routers can identify suchmalicious clients and routers before the mobile clients start using theaccess routers as gateways and the access routers start providingforwarding service to the clients.

[0041] The security mechanism according to the present invention buildsupon authentication, authorization and accounting (AAA) protocols. AAAprotocols, such as RADIUS and DIAMETER, are in use within the Internettoday to provide authentication, authorization and accounting servicesfor dial-up computers. Such AAA administrative services, particularlythe authentication service provided by the AAA servers, are equallyvaluable for Mobile IP. In fact, Mobile IP can be implemented on the AAAinfrastructure with very little changes to their basic frameworks. Forinstance, clients in AAA protocols are considered mobile nodes in MobileIP. Access routers in Mobile IP fit in the position of attendants in AAAprotocols. By augmenting the functionality of mobile clients and accessrouters so that they can understand the AAA messages, it is thenpossible to implement Mobile IP on the AAA infrastructure.

[0042]FIGS. 3A and 3B are simplified graphical representations showing ageneric AAA network model on which NAS (Network Access Services) andMobile IP are implemented. AAA protocols define administrative domains.An administrative domain consists of a network or a collection ofnetworks operating under a common administration. Within the IP network100 illustrated in FIG. 1, a number of administrative domains may bedefined. But for simplicity, the AAA network, as shown in FIGS. 3A and3B, is represented by only two administrative domains, i.e., home andforeign domains 300 and 400 separated by the wide-area Internet. Each ofthe domains comprises an AAA server for providing AAA services toconstituents of its own domain. The home domain 300 is served by a homeserver AAAH 310. The foreign domain 400 is served by a foreign serverAAAF 410. Each of the home and foreign domains further comprisesattendants located within its domains, although FIGS. 3A and 3B showthat only the foreign domain 400 has two attendants 420 and 421.Pursuant to AAA protocols, the attendants 420 and 421 provide theservice interface between the client 320 and the local domain 400. It isassumed in this embodiment that the client 320 originated from the homedomain 300 and has migrated into the foreign domain 400 and that theclient 320 is now wishing to obtain service from either attendant 420 or421 within the administrative domain 400. As mentioned above, Mobile IPis implemented on the AAA network illustrated in FIGS. 3A and 3B. Fromthe Mobile IP perspective, the attendants 323 and 324 are in fact accessrouters (AR) for providing network access service to mobile clients.Therefore, the term “attendant” may be used interchangeably with theterm “access router” or simply “AR.”

[0043] One of the important services provided by AAA protocols isauthentication. Generally, the AAA authentication mechanism works insuch a way that a first AAA entity wishing to communicate with a secondentity presents a credential to the second entity, and communication isallowed to begin between the two entities only when the second entitycan successfully validate the credential of the first entity. Validationof the credential is conducted, using a key algorithm defined in asecurity association (SA) established between the two entities. AAAprotocols are designed to work with different key algorithms. Somealgorithms rely on the existence of a public key infrastructure whileothers rely on distribution of symmetric keys. AAA servers function askey distribution centers and at the request of AAA entities, such asattendants and clients, create and distribute keys for use in validatingcredentials presented between two AAA entities. A distribution of keysto two AAA entities creates a security association between them. It isassumed for the description purpose only that the AAA network shown inFIGS. 3A and 3B adopts a symmetric key or shared secret key algorithm.The symmetric key algorithm is easier to deploy than any other keyalgorithms and thus provides solutions for Internet-wide applicability.However, those skilled in the art will appreciate that other keyalgorithms, such as asymmetric key algorithms such as a public keyscheme, may also be adopted in implementation of the present invention.The use of authentication tokens may be another alternative.

[0044] There is a security model implicit in the AAA network shown inFIGS. 3A and 3B. FIG. 4 shows such an implicit security model in whicharrows indicate pre-established security associations assumed from thebeginning. First, it is assumed that there is a security associationestablished between AAAF 410 and ARs 420 and 421 as indicated by ArrowSA1. It is fair to assume that the ARs 420 and 421 and the AAAF 410 havethe pre-established SA1 between them because the ARs are located in thedomain served by the AAAF 410, and there should have been trust alreadyestablished between them. Next, it is assumed that there is a securityassociation established between AAAH 310 and AAAF 410. These AAA serversdo not need to have a pre-established security association between theminitially but must have the ability to negotiate a security associationwith each other when necessary. This security association, which isindicated by Arrow SA2, can be established directly between the two AAAservers or indirectly through a broker AAA server 200. Lastly, it isassumed that there is a security association established between client320 and AAAH 310, which is indicated by Arrow SA3. Pre-establishment ofthe SA3 is a fair assumption because the client 320 originated from thehome domain 300 in which the AAAH 310 is located. Thus, the AAAH 310 isthe only entity that can authenticate the client initially.

[0045] An important feature of the present invention is that the presentinvention uses Router Discovery mechanism as a “carrier” forimplementing the AAA security protocols in a Mobile IP setting. In thepresent invention, Router Solicitation and Router Advertisement areextended to provide Mobile IP authentication functionality to theexisting AAA protocols.

INITIAL ROUTER DISCOVERY (ENTERING A NEW DOMAIN)

[0046]FIG. 5A is a flow chart that illustrates a network accessauthentication using router discovery protocol, according to anembodiment of the present invention. FIG. 5B is a simplified graphicalrepresentation of the process flow illustrated in FIG. 5A. In thisembodiment, it is assumed that the client 320 does not have any securityassociation either with AR 420 or 421 or with the AAAF 410. In otherwords, it is assumed that the client 320 has never visited the foreigndomain 400 before or has been out of the foreign domain long enough thatthe prior security associations with the ARs 420 and 421 and the AAAF420 have all expired.

[0047] The client 320 enters the foreign domain 400 and requests serviceby an on-link access router for network access. In Step 501, the client320 begins router discovery by sending out an extended RouterSolicitation message (RS+). This is a multicast message which isreceived by all access routers on the same link as the client. Unlike aregular router solicitation message, this one includes the proof ofclient's identity. This proof is carried in the form of extensions tothe standard router solicitation packet. The extended RouterSolicitation (RS+) includes various components such as a standard routersolicitation message (RS). The RS+ also carries the client's identifier(client_id), which can be a network access identifier (NAI) or an IPaddress, and a signature of the client. The signature is a digest of theextended Router Solicitation (RS+) encrypted by a secret key of theclient (client-AAAH_key) shared with the AAAH 310. Thus, the extendedRouter Solicitation (RS+) may be expressed by:

RS+client_id+signed by client.

[0048] The client's shared secret key is defined by the securityassociation SA3 (see FIG. 4) established between client 320 and AAAH410. Thus, the AAAH 410 has the client's shared secret key(client-AAAH_key) to verify the client's signature stored in theextended Router Solicitation (RS+). The AR 420 and other attendantsreceive the extended Router Solicitation (RS+) from the client 320. Asassumed above, however, since the AR 420 does not have a securityassociation with the client 320, it does not have the shared secret keyto verify the identity of client 320. According to the standard RouterDiscovery mechanism, access routers return Router Advertisements inresponse to a Router Solicitation. However, in the present invention,the AR 320 and other access routers will not return RouterAdvertisements until the client 320 is successfully authenticated.

[0049] The AR 420 then delegates the verification of client 320 to theAAAF 410. The AR 420 prepares an AAA Request (AAA Req) and sends it tothe AAAF 410 (Step 503). The AAA Req carries a copy of the entireextended Router Solicitation (RS+) from the client 320. The AAA Req sentfrom the AR 420 to the AAAF 410 is protected according to the securityassociation SA1 established between them. The AAA Req message isprepared according to an AAA protocol, such as Radius or DIAMETER.Preferred procedures for preparing AAA messages are discussed in IETFdraft documents, “Diameter Base Protocol”<draft-ietf-aaa-diameter-07.txt> and “Diameter Mobile IP extensions”<draft-calhoun-diameter-mobileip-12.txt>, both of which are incorporatedherein by reference.

[0050] As assumed above, the AAAF 410 does not have a securityassociation with the client 320 and thus does not have the client'sshared secret key to verify the identity of the client. But theidentifier of the client stored in the RS+ indicates to the AAAF 410that the client 320 has originated form the domain 300. The AAAF 410then forwards the AAA Req, along with a copy of the RS+, to the AAAH 310located in the domain 300 (Step 505), using the security association SA2established with the AAAH 310.

[0051] When receiving the AAA Req from the AAAF 410, the AAAH 310verifies the identity of client 320 by decrypting the client's signaturestored in the AAA Req, using the client's share secret key. If theclient holds out the true identity, the AAAH 310 should be able tosuccessfully verify the identity of client. If the AAAH 310 fails toverify the client's identity, it prepares an AAA Reply (AAA Rep) andsends it to the AR 420 through the AAAF 410. The AAA Rep includes theauthentication result indicating that the AAAH failed to authenticatethe client 320. The AAA Rep message is likewise prepared according to anAAA protocol, such as Radius or DIAMETER. When receiving the AAA Rep,the AR 420 just ignores the Router Solicitation from the client and willnot return a Router Advertisement, whereby unauthenticated mobileclients are prevented from having access to network resources.

[0052] If the AAAH 310 successfully verifies the identity of client 320,the AAAH 310 replies to the AAA Req from the AAAF 410 by preparing anAAA reply (AAA Rep) and transmitting it to the AAAF 410 (Step 507). ThisAAA Rep carries two shared secret keys: one to be used between client320 and AR 420; and the other to be used between client 320 and AAAF410. These shared secret keys are produced by the AAAH and to bedelivered to the AAAF 410, AR 420 and the client 320 to establish asecurity association between client 320 and AAAF 410 and between client320 and AR 420. Each of the secret keys (client-AR_key) and(client-AAAF_key) is duplicated. The duplicates (client-AR_key andclient-AAAF_key) are encrypted by the AAAH 410, using the secret key(client-AAAH_key) shared with the client 320, to protect theirauthenticity and confidentiality and delivered to the client 320. Theoriginal keys (client-AR_key and client-AAAF_key) are unencrypted anddelivered to the AR 420 and the AAAF 410, respectively. Thus, the AAARep from the AAAH 310 to the AAAF 410 may be expressed by:

client-AR_key+client-AAAF_key+(client-AR_key+client-AAAF_key) encryptedby AAAH.

[0053] This AAA Rep from the AAAH 310 informs the AAAF 410 that theclient 320 is trustworthy. The AAAF 410 then extracts the unencryptedshare secret key (client-AAAF_key) from the AAA Rep and stores it in itscache. The shared secret key extracted is going to be used by the AAAF410 to authenticate messages from the client 320. The AAAF 410 thenforwards the AAA Rep to the AR 420 (Step 509). The AAA Rep from the AAAF410 informs the AR 420 that the identity of client 320 has beensuccessfully authenticated. The AR 420 then extracts the unencryptedshared secret key (client-AR_key) from the AAA Rep and stores it in itscache. This shared secret key is going to be used by the AR 420 toauthenticate messages from the client 320. The AR 420 then prepares anextended Router Advertisement (RA+) and unicasts it to the client 320(Step 511). The extended Router Advertisement (RA+) includes a standardRouter Advertisement message (RA), the identification of AR 420 (AR_id)and the shared secret keys (client-AR_key and client-AAAF_key) encryptedby the shared secret key (client-AAAH_key). It further includes asignature of the AR. The signature is a digest of the RA+ encrypted bythe shared secret key (client-AR_key), which the AR just received fromthe AAAF 410. Thus, the extended Router Advertisement may be expressedby:

RA+AR_id+(client-AR_key+client-AAAF_key) encrypted by AAAH+signed by AR.

[0054] When receiving the extended Router Advertisement (RA+) from theAR 420, the client 320 verifies the authenticity of the received routeradvertisement. The client 320 first decrypts the shared secret keys(client-AR_key and client-AAAF_key), using the secret key shared withthe AAAH 310 (client-AAAH_key). If these secret keys are successfullydecrypted, the client 320 can trust the secret keys because they arecertified by the AAAH 310, which the client trusts. Next, the client,using the decrypted secret key (client-AR_key), decrypts the signatureof the AR 420. If the signature is successfully decrypted, the client320 can trust the AR 420 because the identity of the AR is verified bythe secret key (client-AR_key), which the client now trusts. Also,successful decryption of the signature assures the client of theauthenticity of the extended Router Advertisement (RA+). With the sharedsecret key (client-AR_key), which is distributed to the client 320 andthe AR 420, a new security association SA4 (FIG. 6) is establishedbetween client 320 and AR 420. With the shared secret key(client-AAAF_key), which is distributed to the client 320 and the AAAF410, a new security association SA5 is established between client 320and AAAF 410.

[0055] If the client 320 fails to authenticate the signature of the AR420, the client 320 just ignores the Router Advertisement from the AR420 and waits for Router Advertisements from other access routers thatcarry verifiable signatures. By doing so, the client 320 is preventedfrom being lured to begin network access via an illegitimate accessrouter.

[0056] The authentication process shown in FIGS. 5A and 5B probablytakes long time and causes significant communication latency. A majorcomponent of this communication latency is the time taken for the AAAmessages to traverse the wide-area Internet that separates the AAAF 410and the AAAH 310. Anytime an AAA message has to travel to the AAAF orthe AAAH, there is certain latency involved. In the initialauthentication process as shown in FIGS. 5A and 5B, it is inevitable tocommunicate with these remote servers. However, if the AR and the AAAFare able to authenticate the client without consulting the AAAF or theAAAH, then the latency involved in this authentication mechanism will bereduced.

SUBSEQUENT ROUTER DISCOVERY (NEW ACCESS ROUTER, SAME DOMAIN)

[0057] The client may move within the domain 400 and attach to anotheraccess router which is not aware of client's identity. FIG. 7A is a flowchart that illustrates an authenticated router discovery performed insuch a case, according to another embodiment of the invention. FIG. 7Bis a simplified graphical representation of the process flow illustratedin FIG. 7A. In FIGS. 7A and 7B, it is assumed that after the client 320goes through the initial authentication process shown in FIGS. 5A and 5Bwith the AR 420, the client 320 leaves the subnet served by the AR 420and enters the subnet served by the AR 421. To obtain network accessthough the AR 421, the client 320 again sends out an extended RouterSolicitation (RS+) (Step 701). The extended Router Solicitation (RS+)sent out this time carries the same messages as used in the initialauthentication process shown in FIGS. 5A and 5B and may be expressed by:

RS+client_id+signed by client.

[0058] However, since the signature in the extended Router Solicitationin this embodiment is encrypted by the shared key (client-AAAF_key), theAR 421 cannot verify the signature. The AR 421 then delegates theverification of client 320 to the AAAF 410 by preparing and sending anAAA Req to the AAAF (Step 703). The AAA Req from the AR 421 includes acopy of the entire RS+. The AAAF 410 should be able to recognize theidentify of client 320 because it has obtained the share secret key(client-AAAF_key) from the previous authentication process shown inFIGS. 5A and 5B. Without consulting the AAAH 310, the AAAF 410 verifiesthe identity of the client by decrypting the client's signature, usingthe shared secret key (client-AAAF_key). If the AAAF 410 fails to verifythe client's signature, the AAAF 410 prepares an AAA Rep and sends it tothe AR 421 (Step 705) to notify the AR 421 that the client 320 cannot betrusted. The AR 421 then ignores the Router Solicitation from the client320. If the client's signature is successfully verified, the AAAF 410generates a secret key (client-AR2_key) to be shared between the client320 and the AR 421. The secret key (client-AR2_key) is then duplicated.One is unencrypted, but the other is encrypted by the share secret key(client-AAAF_key). The AAAF 410 stores the unencrypted key and theencrypted key in an AAA Rep and sends it to the AR 421 (Step 705). Thus,the AAA Rep from the AAAF 410 to the AR 421 may be expressed by:

client-AR2_key+(client-AR2_key) encrypted by AAAF.

[0059] The AAA Rep from the AAAF 410 informs the AR 421 that the client320 can be trusted. The AR then extracts the unencrypted secret key(client-AR2_key) and stores in its cache. This stored secret key isgoing to be used by the AR 421 to authenticate future messages from theclient 320. The AR 421 then prepares an extended Router Advertisement(RA+) and unicasts it to the client 320 (Step 707). The extended RouterAdvertisement from the AR 421 may be expressed by:

RA+AR_id+(client-AR2_key) encrypted by AAAF+signed by AR.

[0060] When receiving the Router Advertisement (RA+) from the AR 421,the client 320 first decrypts and extracts the secret key(client-AR2_key), using the shared secret key (client-AAAF_key). If thekey is successfully decrypted, the client 320 may trust the key. Usingthe shared secret key (client-AR2_key), the client then verifies theauthenticity of the RA+ by decrypting the signature of the AR 421. Ifthe signature is successfully decrypted, the client 320 can trust the AR421 and the authenticity of the RA+. With the shared secret key(client-AR2_key), which is distributed to the client 320 and the AR 421,a new security association is established between them. If the clientfails to decrypt the signature, the client ignores the RouterAdvertisement from the AR 421 and waits for Router Advertisements fromother access routers that carry verifiable signatures.

[0061] The subsequent authentication process shown in FIGS. 7A and 7B isfaster to perform, compared to the process shown in FIGS. 5A and 5Bbecause the authentication process shown in FIGS. 7A and 7B does notrequire exchange of messages with the AAAH 310 and thus consists of ashorter round trip for protocol signaling.

SUBSEQUENT ROUTER DISCOVERY (SAME ACCESS ROUTER)

[0062] Each Router Advertisement has a lifetime. Thus, even if a clientis still attached to the same access router, the client has to gothrough an authentication process with the same access router before thelifetime of the previous Router Advertisement expires. In such a case,however, the authentication process according to the present inventiontakes the shortest round trip for protocol signaling as shown in FIGS.8A and 8B. In FIGS. 8A and 8B, the client 320 in Step 801 sends out anextended Router Solicitation to the AR 420. The extended RouterSolicitation may be expressed by:

RS+client_id+signed by client.

[0063] The signature is encrypted by the shared secret key(client-AR_key), which the client has obtained from the previous initialauthentication process shown in FIGS. 5A and 5B. The AR 420 should beable to recognize the identity of the client because it shares the samekey with the client 320. Without consulting the AAAF 410, the AR 420verifies the identity of client 320 by decrypting the signature, usingthe shared secret key (client-AR_key). If the AR 420 fails to verify theidentity of the client, it just ignores the Router Solicitation. If theAR 420 successfully verifies the client's identity, it prepares anextended Router Advertisement (RA+) and unicasts it to the client 320.The extended Router Advertisement (RA+) in this embodiment may beexpressed by:

RA+AR_id+signed by AR.

[0064] Thus, this communication between client 320 and AR 420 provides afastest authentication mechanism because it involves the shortest roundtrip for protocol signaling.

UNSOLICITED ROUTER ADVERTISEMENTS

[0065] Access routers may periodically send Router Advertisements,instead of waiting to receive a verifiable Router Solicitation. It isassumed in FIG. 9 that the ARs 420 and 421 unicast their extended RouterAdvertisements (RA+) periodically. These extended Router Advertisementsmay be expressed by:

RA+AR_id+signed by AR.

[0066] The extended Router Advertisements sent from the AR 420 contain astandard Router Advertisement message (RA) and a signature of AR 420.The extended Router Advertisements sent from the AR 421 contain astandard Router Advertisement message (RA) and a signature of AR 421. Itis assumed that the client 320 has previously gone through the initialauthentication process shown in FIGS. 5A and 5B with the AR 420. Throughthis previous authentication process, there are a security associationestablished between client 320 and AR 420 and between client 320 andAAAF 410. If the extended Router Advertisements from the AR 420 reachthe client 320, the client 320 should be able to authenticate the routeradvertisement messages. Thus, the client 320 can safely choose to beginnetwork access via the AR 420. If the client does not recognize any ofthe Router Advertisements it receives, the client will have to gothrough the initial authentication process shown in FIGS. 5A and 5B bysending out extended Router Solicitations.

RE-AUTHENTICATION

[0067] At any time either of client and AR which are in communicationmay start the authentication process according to the present inventionto re-authenticate each other. This is important because there is alwaysthe possibility that malicious entities may replace legitimate ones evenduring communication. The client may start this process by sending anextended Router Solicitation (RS+) at any time during communication withthe AR. The AR should be able to respond to the RS+ by returning to theclient its extended Router Advertisement (RA+) for re-authentication bythe client. Likewise, the AR, while serving a client, canre-authenticate the client. The AR begins the re-authentication of theclient by sending the client a unicast Router Advertisement with a verylow router lifetime. A very low router lifetime indicates to the clientthat the AR is about to stop serving the client. The client responds tosuch a Router Advertisement by sending out a RS+ to discover otheravailable routers on the same link. The AR then authenticates the RS+sent from the client.

INTEROPERATION WITH OLD PROTOCOL

[0068] Within an overall network, domains may jointly exist that cansupport the extended Router Discovery according to the present inventionand support only the standard Router Discovery. Thus, there may asituation where a client that supports only the standard RouterDiscovery happens to migrate into a domain that supports the extendedRouter Discovery according to the present invention. Or a client thatsupports the extended Router Discovery migrates into a domain thatsupports only the standard Router Discovery. In either situation, theauthentication protocol according to the present invention will notinterfere with the operation of the standard Router Discovery.

[0069] First, in a situation where a client that supports the extendedRouter Discovery tries to obtain connectivity service within a domainthat supports only the standard Router Discovery, the client sends outan extended Router Solicitation (RS+). However, nearby access routerscannot recognize new extensions attached to the Router Solicitation andthus will ignore these extensions. The access routers will process theextended Router Solicitation (RS+) as a standard Router Solicitation(RS) and send back a standard Router Advertisement (RA). Now it is up tothe client to decide whether to use this “unauthenticated” advertisementor not.

[0070] In the next situation where a client that supports only thestandard Router Discovery tries to obtain service within a domain thatsupports the extended Router Discovery according to the presentinvention, the client sends a standard Router Solicitation (RS) thatdoes not include any of the new extensions. Upon receiving such an“unauthenticated” solicitation, it is up to nearby access routerswhether to send back an extended Router Advertisement (RA+) or not torespond at all.

[0071] In either case, client and AR that support the extended RouterDiscovery according to the present invention can detect whether theother side of the communication can support the extended RouterDiscovery or only the standard Router Discovery, and respondaccordingly. Whether to respond to or accept unauthenticated messages isa policy decision.

PROTECTION AGAINST REPLAY ATTACK

[0072] A replay attack is simply a replay of a stolen password. If acracker can listen in when a password is being transmitted, the crackerthen has a copy of your password that can be used at any time in thefuture. Even if the password is communicated in encrypted form, thecracker may be able to log in by simply replaying a previously capturedcommunication. With addition of challenge extensions, the authenticationprotocol according to the present invention can provide protectionagainst replay attacks.

[0073]FIG. 10 is a flow chart showing an embodiment of the presentinvention in which a challenge scheme is used to provide protectionagainst replay attacks. In FIG. 10, it is assumed that the client 320has never communicated with the AR 420 or the AAAF 410, and thus theclient 320 has to go though the initial authentication process as shownin FIGS. 5A and 5B. First, the client 320 sends out a standard RouterSolicitation (RS) (Step 1001). The AR 420 receives the RouterSolicitation, but cannot trust it until the identity of client sendingthe solicitation message is authenticated. The client sending thesolicitation message may be a malicious node that has monitored pastcommunication of the client 320 and stolen the identity of the client320 in order to obtain network access under the false ID.

[0074] In return to the Router Solicitation (RS) from the client 320,the AR 420 challenges the identity of the client and the authenticationof the solicitation message (Step 1003). Specifically, in Step 1003, theAR 420 unicasts a Router Advertisement (RS), along with a challengeextension, to the client 320. The challenge extension includes a randomnumber generated by the AR 420. Triggered by the Router Advertisementfrom the AR 420, the client prepares and sends an extended RouterSolicitation (RS*) (Step 1005). The extended Router Solicitationincludes a standard Router Solicitation (RS), the identification of theclient, i.e., the client's IP address or NAI, and a request for a secretkey to be shared with the AR 420 to establish a security associationwith the AR 420. The extended Router Solicitation (RS*) further includestwo challenge extensions. One challenge extension includes a copy of thechallenge that the client just received from the AR in Step 1003. Thesecond challenge extension includes a random number generated by theclient itself. Lastly, the RS* includes an authentication extensionincluding a signature of the client 320 that is encrypted, using asecret key shared between client 320 and AAAH 310 (client-AAAH_key).Thus, in this embodiment, the extended Router Solicitation (RS*) may beexpressed by:

RS+client_id+client-AR_key_request+Chal_AR+Chal_client+signed by client.

[0075] When receiving the RS* from the client 320, the AR 420 firstchecks the challenge extension Chal_AR to see if the random number inthe extension is the same as the number that it sent to the client rightin Step 1003. If the random number is the same, it is the case that theRS* is in fact a response to the challenge that the AR 420 sent to theclient 320 in Step 1003. If the numbers do not match, the AR 420 mustignore the RS* because the RS* is probably from a malicious node that ispretending to be the client 320 with a stolen ID. If the numbers match,the subsequent authentication process will be the same as previouslydescribed with FIGS. 5A and 5B.

[0076] If the identity of the client 320 is successfully verified by theAAAH 310, the AR 420 prepares and unicasts an extended RouterAdvertisement (RA*) to the client 320 (Step 1007). In this embodiment,the extended Router Advertisement (RA*) includes a standard RouterAdvertisement and a secret key (client-AR_key) to be shred betweenclient 320 and AR 420. The secret key has been generated by the AAAH310. As already discussed, the key is encrypted, using the secret key(client-AAAH_key) shared between client 320 and AAAH 310. The RA*further includes two challenge extensions. One extension includes a copyof the random number that the AR 420 received from the client in Step1005. The other challenge extension includes a new random numbergenerated by the AR 320, which will be used in a next communicationbetween client 320 and AR 420. The RA* also has an authenticationextension that includes a signature of the AR 420 that is encrypted,using the newly distributed shared secret key (client-AR_key). Thus, theextended Router Advertisement in this embodiment may be expressed by:

RA+AR_id+client_AR_key_reply+Chal_client+Chal_AR+signed by AR.

[0077] When receiving the RA* from the AR 420, the client 320 firstchecks the challenge extension (Chal_client) to see if the random numberin the extension is the same as that the client sent to the AR in Step1005. If the numbers do not match, the client must disregard the RA*because it may be the case that a malicious access router is pretendingto be the AR 420 with the stolen ID. If the numbers match, the client320 extracts the number in the challenge extension (Chal_AR) and storesin its cache for future communication with the AR 420. The client 320then decrypts the key reply (client_AR_key_reply) to extract the secretkey (client-AR_key) shared with the AR, using the secret key(client-AAAH_key) shared with the AAAH 310. Using the extracted sharedsecret key, the client then verifies the signature of the AR 420.

[0078] After the initial authentication process as shown in FIG. 10 isperformed, i.e., after a security association is established betweenclient 320 and AR 420, the client and the AR may re-authenticate them toeach other. FIG. 11 shows an example of such a re-authenticationprocess. The re-authentication process is initiated by the client 320,which sends out an extended Router Solicitation (RS*) (Step 1101). Inreturn, the AR 420 unicasts an extended Router Advertisement (RA*) (Step1103). Since a security association has already been established betweenclient 320 and AR 420, the RS* may be expressed as follows:

RS+client_id+Chal_AR+Chal_client+signed by client.

[0079] The challenge extension (Chal_AR) in the RS* contains the randomnumber copied from Step 1007. The challenge extension (Chal_client)contains a new random number generated by the client.

[0080] The RA* may be expressed by:

RA+AR_id+Chal_client+Chal_AR+signed by AR.

[0081] The challenge extension (Chal_client) in the RA* contains therandom number copied from Step 1101. The challenge extension (Chal_AR)contains a new random number generated by the AR.

AUTHENTICATION USING ASYMMETRIC KEY SCHEME

[0082] In the above embodiments, the authentication protocol accordingto the present invention is discussed, using an AAA infrastructure thatadopts a symmetric key scheme, i.e., a shared secret key algorithm. Asthose skilled in the art can appreciate, the authentication protocolaccording to the present invention, of course, works with an asymmetrickey scheme, such as public key algorithm. How the authenticationprotocol according to the present invention works with the public keyalgorithm will be explained with reference to FIG. 12. In FIG. 12, it isassumed that the client 320 just enters the domain 400, which the clienthas never visited before. Therefore, the client 320 has to go throughthe initial authentication process.

[0083] (1) The client 320 begins router discovery by sending out anextended Router Solicitation message (RS+). The extended RouterSolicitation (RS+) in this embodiment includes a standard routersolicitation message (RS). The RS+ also carries the client's identifierand a signature of the client 320. The signature is a digest of theextended Router Solicitation (RS+) encrypted by the secret key of theclient. Thus, the extended Router Solicitation (RS+) may be expressedby:

RS+client_id+signed by client.

[0084] The client's secret key is defined by the security associationSA3 (see FIG. 4) established between client 320 and AAAH 410. Thus, theAAAH 410 has the client's public key to verify the client's signaturestored in the extended Router Solicitation (RS+). In the settingillustrated in FIG. 12, the AAAH 410 is the only entity that can verifythe client's signature.

[0085] (2) The AR 420 receives the extended Router Solicitation (RS+)from the client 320 but cannot verify the client's signature because itdoes not have the public key to decrypt the signature. The AR 420 thenprepares an AAA Request (AAA Req) and sends it to the AAAF 410 alongwith a copy of the entire RS+.

[0086] (3) The AAAF 410 does not have the client's public key and cannotverify the client's signature. The AAAF 410 then places its public keyinto the AAA Req and forwards it to the AAAH 310.

[0087] (4) When receiving the AAA Req from the AAAF 410, the AAAH 310verifies the identity of client 320 by decrypting the client's signaturestored in the AAA Req, using the public key of client. If the AAAH 310successfully verifies the client's signature, the AAAH 310 replies tothe AAA Req by preparing an AAA reply (AAA Rep) and transmitting it tothe AAAF 410. This AAA Rep carries the public key (PK) of client 320 anda certificate of AAAF 410. The certificate of AAAF 410 is prepared byextracting the public key of AAAF 410 from the AAA Req and encryptingit, using the secret key of AAAH 310, which is defined by thepre-established security association SA3. Thus, the AAA Rep from theAAAH 310 to the AAAF 410 may be expressed by:

PK of client+AAAF certified by AAAH.

[0088] (5) The AAAF 410 extracts the public key of the client 320 fromthe AAA Req and stores it in its cache. The public key extracted isgoing to be used by the AAAF 410 to authenticate messages from theclient 320. The AAAF 410 then prepares a certificate of AR 420, placesthe certificate in the AAA Rep and sends the AAA Rep to the AR 420. Thecertificate of AR 420 includes the public key (PK) of AR 420, which issinged by the secret key of AAAF 410. Thus, the AAA Rep from the AAAF410 to the AR 420 may be expressed by:

PK of client+AR certified by AAAF+AAAF certified by AAAH.

[0089] (6) When receiving the AAA Rep from the AAAF 410, the AR 420extracts the public key of the client and stores it in its cache. Thepublic key of the client is going to be used by the AR 420 toauthenticate messages from the client 320. The AR 420 then prepares anextended Router Advertisement (RA+) and unicasts it to the client 320.The extended Router Advertisement (RA+) includes a standard RouterAdvertisement message (RA) and further includes the certificate of AR420 prepared by the AAAF 410 and the certificate of AAAF 410 prepared bythe AAAH 310. Thus, the extended Router Advertisement may be expressedby:

RA+AR_id+AR certified by AAAF+AAAF certified by AAAH+signed by AR.

[0090] When receiving the extended Router Advertisement (RA+) from theAR 420, the client 320 verifies the authenticity of the received routeradvertisement. The client 320 first decrypts the certificate of AAAF 410to extract the public key of the AAAF 410, using the public key of AAAH310. The public key is from the pre-established security association SA3between client 320 and AAAH 310. If the certificate is successfullydecrypted, the client 320 can trust the extracted public key of AAAF 410because it is certified by the AAAH 310, which the client trusts. Next,the client, using the extracted public key of AAAF 410, decrypts thecertificate of AR 420 to extract the public key of AR 420. If thecertificate is successfully decrypted, the client 320 can trust thepublic key of the AR because it is certified by the AAAF 410, which theclient now trusts. With the public keys of AR 420 and AAAF 410, whichare distributed to the client 320, new security associations SA4 and SA5(FIG. 6) are established between client 320 and AR 420 and betweenclient 320 and AAAF 410.

[0091] What have been described are preferred embodiments of the presentinvention. The foregoing description is intended to be exemplary and notlimiting in nature. Persons skilled in the art will appreciate thatvarious modifications and additions may be made while retaining thenovel and advantageous characteristics of the invention and withoutdeparting from its spirit. Accordingly, the scope of the invention isdefined solely by the appended claims as properly interpreted.

1. An authentication process comprising the steps of: sending out from amobile client a solicitation message that contains a proof of identityof the mobile client; verifying the proof by a trusted entity; andreturning an advertising message from an access router only when theproof is successfully verified.
 2. An authentication process as recitedin claim 1, further comprising the step of certifying by the trustedentity to the mobile client any intermediate entities located betweenthe mobile client and the trusted entity.
 3. An authentication processas recited in claim 1, wherein the process is used in a communicationnetwork comprising a plurality administrative domains each served by atleast one administrative server and each having at least one accessrouter.
 4. An authentication process as recited in claim 3, wherein thetrusted entity is a server serving a home domain to which the mobileclient belongs.
 5. An authentication process as recited in claim 3,wherein the trusted entity is a server serving a foreign domain visitedby the mobile client.
 6. An authentication process as recited in claim3, wherein the trusted entity is an access router that has received thesolicitation message from the mobile client.
 7. An authenticationprocess as recited in claim 1, wherein the advertising message containsa proof of identity of the access router for authentication by themobile client.
 8. An authentication process as recited in claim 1,further comprising the steps of: voluntarily sending out from a mobilityserving node an advertising message that contains a proof of theidentity of the access router; verifying the proof by a mobile client;and performing the steps recited in claim 1 when the mobile client isunable to verify the proof.
 9. An authentication process as recited inclaim 1, wherein the steps recited in claim 1 are performed while themobile client is in communication with the access router tore-authenticate the access router to the mobile client, and wherein theadvertising message from the access router contains a proof of identityof the access router.
 10. An authentication process as recited in claim1, wherein an access router, while in communication with a mobileclient, sends out an advertisement message with short effective lifetimeto initiate the steps recited in claim 1 in order to re-authenticate themobile client to the access router.
 11. An authentication process asrecited in claim 1, wherein IPv4 is adopted for data communication. 12.An authentication process as recited in claim 1, wherein IPv6 is adoptedfor data communication.
 13. An authentication process as recited inclaim 1, wherein the verification is performed, using an asymmetric keyalgorithm.
 14. An authentication process as recited in claim 1, whereinthe verification is performed, using a symmetric key algorithm.
 15. Anauthentication process as recited in claim 1, wherein at least one ofthe solicitation message and the advertising message includes achallenge.
 16. A mobile client comprising: a transmitter for sending outa solicitation message that contains a proof of identity of the mobileclient; and a receiver for receiving an advertising message from anaccess router, wherein the mobile client receives the advertisingmessage only when the proof is successfully verified.
 17. A mobileclient as recited in claim 16, wherein the advertising message containsa proof of identity of the access router, and the mobile client iscapable of verifying the proof.
 18. A mobile client as recited in claim16, wherein the transmitter sends out the solicitation message to theaccess router while the mobile client is in communication with theaccess router in order to re-authenticate the access router.
 19. Amobile client as recited in claim 16, wherein IPv4 is adopted for datacommunication.
 20. A mobile client as recited in claim 16, wherein IPv6is adopted for data communication.
 21. A mobile client as recited inclaim 16, wherein the verification is performed, using an asymmetric keyalgorithm.
 22. A mobile client as recited in claim 16, wherein theverification is performed, using a symmetric key algorithm.
 23. A mobileclient as recited in claim 16, wherein at least one of the solicitationmessage and the advertising message includes a challenge.
 24. An AAAnetwork comprised of a plurality of administrative domains each servedby at least one administrative server and each having at least oneaccess router deployed therein, comprising: a mobile client that sendsout a solicitation message that contains a proof of identity of themobile client; a trusted entity that verifies the proof; and an accessrouter that returns an advertising message only when the proof issuccessfully verified.
 25. An AAA network as recited in claim 24,wherein the trusted entity certifies to the mobile client anyintermediary entities located between the mobile client and the trustedentity.
 26. An AAA network as recited in claim 24, wherein the trustedentity is a server serving a home domain to which the mobile clientbelongs.
 27. An AAA network as recited in claim 24, wherein the trustedentity is a server serving a foreign domain visited by the mobileclient.
 28. An AAA network as recited in claim 24, wherein the trustedentity is an access router that has received the solicitation messagefrom the mobile client.
 29. An AAA network as recited in claim 24,wherein the advertising message contains a proof of the identity of theaccess router for authentication by the mobile client.
 30. An AAAnetwork as recited in claim 24, wherein the access router voluntarilysends out an advertisement message that contains a proof of identity ofthe access router, and the mobile client verifies the proof and sendsout the solicitation message when it is unable to verify the proof. 31.An AAA network as recited in claim 24, wherein the mobile client sendsout the solicitation message while in communication with the accessrouter, and the access router sends out an advertising message thatcontains a proof of identity of the access router for authentication bythe mobile client.
 32. An AAA network as recited in claim 24, whereinthe access router, while in communication with the mobile client, sendsout an advertisement message with a short lifetime to induce the mobileclient to send out the solicitation message.
 33. An AAA network asrecited in claim 24, wherein IPv4 is adopted for data communication. 34.An AAA network as recited in claim 24, wherein IPv6 is adopted for datacommunication.
 35. An AAA network as recited in claim 24, wherein theverification is performed, using an asymmetric key algorithm.
 36. An AAAnetwork as recited in claim 24, wherein the verification is performed,using a symmetric key algorithm.
 37. An AAA network as recited in claim24, wherein at least one of the solicitation message and the advertisingmessage contains a challenge.